|
|
|
|
|
|
|
times, time is so precious that you don't have time to review the latest technology. In the short run, this might not impact you, unless you're working with antiquated technology. However, in the long run, the organization stands to lose a competitive advantage with its peers in its industry. That is, if your organization's peers have successfully separated the task of reviewing new technology from the task of developing software, they increase their chances of boosting worker productivity from the use of the new stuff. By the time your organization decides to separate the tasks, it might be too far behind. |
|
|
|
|
|
|
|
|
When possible, try to convince management to consider creating a technology review team, or at least a technology review individual. Avoid the temptation to overindulge in new technology reviews when you have pressing deadlines. It might seem harmless to do so in the initial honeymoon of a new project, but this lost time tends to come back to haunt you later. If your organization cannot afford to have a distinct technology review team, explain to them that reviewing new technology can sometimes have an adverse impact on project deadlines. |
|
|
|
|
|
|
|
|
The Object and Application Repository Caretaker |
|
|
|
|
|
|
|
|
Related to the previous section, having an object and application repository caretaker ensures that objects you develop get published in a corporate development repository. Generally, this caretaker will interact with you at the end of your iterations, when your objects are typically ready for publication. Nonetheless, it is advisable to work with the caretaker at the actual end of the project. |
|
|
|
|
|
|
|
|
Why at the end of the project and not the beginning? Although you can achieve reuse of use cases early in the analysis phase, there's no way to gauge reuse of implemented objects up front until you've elaborated the use cases into design diagrams and models and then in code. The coding is where you judge where code reuse begins and ends. Before that, the analysis and design cannot dictate reuse accurately in code, only reuse in analysis and design. Not realizing this important point can cause frustration with the object-oriented programming process. Some developers who try to achieve reuse too soon generally find that what they analyzed and designed was not a good basis for judging code reuse. In general, you achieve or identify patterns of use case reuse in analysis, design reuse in design, and code reuse during construction or implementation. Added to this is the fact that even when judging code reuse, you don't know it's reusable until you've used the classes over several projects. |
|
|
|
|
|
|
|
|
The Enterprise Architecture and Reuse Team |
|
|
|
|
|
|
|
|
Similar to the team in the previous section, the enterprise architecture and reuse team looks for opportunities of reuse among all of the repositories across an enterprise. This |
|
|
|
|
|